This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
Policy and Charging Control Architecture
Mobile TV involves bringing TV services to mobile devices. It combines the services of a mobile device with television content and represents a logical step both for consumers and operators and content providers. Mobile TV over cellular networks allows viewers to enjoy personalized, interactive TV with content specifically adapted to the mobile medium. The services and viewing experience of mobile TV over cellular networks differs in a variety of ways from traditional TV viewing. In addition to mobility, mobile TV delivers a variety of services including video-on-demand, traditional/linear and live TV programs, interactivity. Another exciting opportunity for users is Mobile TV podcasts, where content is delivered to a user's mobile on demand or by subscriptions. Stored locally on the handset, this content can then be viewed even when there's no network connection. And a service provider can schedule the delivery to “off-peak” hours, for example during the night.
Mobile TV will make use of the 3GPP PCC architecture. PCC will help Mobile TV by setting the right QoS conditions in the network.
Role of the PCC Architecture
In order to be able to provide a satisfactory and reliable service experience, operators need to take special care of the quality, effective charging and potential fraud on the use of the services provided. 3GPP has defined a Policy and Charging Control (PCC) Architecture that helps operators to be in control of the above mentioned issues.
FIG. 1 presents the basic outline of the PCC architecture.
The PCRF sits in between of the Application signaling plane where services are initiated and service characteristics are negotiated (e.g. via SIP/SDP) and the media plane where the actual service is being provided.
In this architecture, PCRF is responsible for accepting or rejecting the service authorization request received from the AF. Upon receiving the session information the PCRF should run the corresponding operator policies and decide whether the new medias can be accepted or not. If accepted, the PCRF will install in the PCEF the corresponding PCC rules derived from the service information received from the AF.
The PCEF will inform the PCRF about the outcome of the PCC rule installation and will initiate the bearer procedures towards the network. If there is any failure in this process, the PCRF will be informed that the enforcement could not take place.
This procedure has been standardized in both 3GPP Rel-7 and Rel-8. See 3GPP TS 29.213[3GPP TS 29.212 v. 8.1.0 Policy and Charging Control over Gx interface (Release 8)]. In Rel-8, for the cases where there are PMIP protocols between the PCEF and the AN-gateway (Access Network Gateway), the PCRF will install QoS rules towards the AN-gateway (known as BBERF, bearer binding and event reporting function). The flow between BBERF and PCRF is equivalent as the one shown here towards the PCEF. For simplicity reasons, only the PCEF is considered in the following flows.
FIG. 2 shows signalling flows of the current message exchange. Steps 11 and 12 will only occur in the negative case.
1. The AF (e.g. a streaming server) receives an internal or external trigger to create/modify an existing AF session and provide related Service Information. Normally this will take place as a result of AF signalling (e.g. SIP/SDP) with the user where e.g. an streaming session has been established.
2. The AF identifies the Service Information needed (e.g. IP address of the IP flow(s), port numbers to be used, information on media types etc. . . . ).
3. The AF provides the Service Information to the PCRF by sending a Diameter AAR for the existing Rx Diameter session corresponding to the AF session.
4. & 5. The PCRF analyses the received Service Information and checks whether the service can be authorized. If possible, the PCRF grants the request and store the service information.
6. The PCRF sends a Diameter AAA to the AF including a positive response to the service authorization request.
7. The PCRF generates the corresponding PCC rules and initiates the IP-CAN Session modification by sending a RAR command.
8. The PCEF installs the received PCC Rules. The PCEF also enables or disables service flow according to the flow status of the corresponding PCC Rules.
9. The PCEF initiates the request for the modification of an IP-CAN bearer and enforces the authorized QoS.
10. The PCEF is notified about the outcome of the IP-CAN bearer initiated procedure.
11. If the procedure fails, the PCEF sends a Diameter CCA towards the PCRF including the PCC rules that could not be enforced.
12. The PCRF acknowledges the request.
Problems with Existing Solutions
The IP-CAN session modification procedure initiated by the PCRF has the following characteristics:                a. The AF is informed about the outcome of the service authorization procedure. However, the AF is not aware of any IP-CAN specific procedure unless it subscribes to the events that are currently defined.        b. When the AF requires to be notified of certain events that occurred in the access network it will provide the Specific-Action AVP in the Rx AAR command. Establishment and Release of Bearer can be subscribed by the application. The notification of the event will come in a new RAR command.        c. In order for the PCRF to notify about an access event to the AF, the PCRF has to subscribe to an equivalent event in the PCEF by using the Event-Trigger AVP in the Gx command. The mapping between events in Rx and Gx is not standardized. For example, there is no event in the Gx to report release of bearer.        d. Errors in the access network cannot be reported to the AF, unless it is mapped into a Specific-Action in Rx. Mapping between errors and specific actions is not standardized.        e. The PCRF can abort the AF session when there is an error in the access network.        
This specific behavior has been acceptable so far as the network has been defined considering IMS as the normal client application for PCC infrastructure. In the case of IMS, the services are peer-to-peer and only the peer entities are involved in the service negotiation.
According to that, the P-CSCF (taking the AF role in PCC architecture) will not demand whether resource reservation has taken place in order to progress the service and will not alter the service negotiation based on specific access information that the PCRF can provide to the P-CSCF once the session is on course. In the normal scenario, when the access conditions cannot be fulfilled, the PCRF will initiate an AF session abortion. From the IMS point of view, PCC interaction should not mean any latency in the progress of the IMS service.
However, there are other applications that start to demand the PCC support. For example, Mobile TV has had a slow take-off due to poor user experience because of phones with poor video capabilities and that the best-effort service had a limited bandwidth (˜100 kbps). However, the situation is improving today with better phones and widespread HSPA rollout.
This new type of services is not peer-to-peer kind of services, but client-to-server services. This means that the PCC architecture can provide relevant information that can influence in the AF service negotiation. This has opened the door to added value functionality that helps operators to provide adapted services considering access information, as QoS availability.
As part of the requirements demanded to the Mobile TV solution, the streaming server needs to be informed about the outcome of the resource reservation in the access network. Based on this information, the terminal can be informed when the QoS demands cannot be ensured or the charging can be adapted accordingly. Latency is also a key requirement here, so the application needs to be informed about the outcome of the bearer operation as soon as possible.
In order to fulfill these new requirements the PCRF initiated IP-CAN session modification procedure has to be adapted so that both kind of applications (IMS and non-IMS) can coexist without penalizing any of them.
With the Current Procedures:
1. Applications that require knowing the resource allocation before the progression of the service are not considered, since there is no specific event/error in the access network.
2. The Rx interface does not consider the resource reservation notification towards the applications.
Additionally, improving the flows for the new applications should not mean a degradation of current IMS services.